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Abstract 

DIAMOND  (Diplomatic  And  Military  Operations  in  a  Non-warfighting  Domain)  is  a  high-level  stochastic 
simulation  developed  at  Dstl  as  a  key  centrepiece  within  the  Peace  Support  Operations  (PSO)  modelling 
jigsaw’.  It  is  designed  to  examine  the  utility  of  military  force  elements  and  equipments,  the  effectiveness  of 
future  force  structures,  and  possible  outcomes  of  different  operational  strategies  within  PSO.  It  represents  the 
differing  parties  in  a  PSO,  which  may  include  military  organisations,  non-combatants,  Non-Governmental 
Organisations  (NGOs)  and  civilians,  together  with  their  relationships. 

1  Introduction 

1.1  Dstl  Policy  and  Capability  Studies 

Dstl  Policy  and  Capability  Studies  (PCS)  is  the  high-level  operational  research  (OR)  arm  of  the  Defence 
Science  and  Technology  Laboratories  (Dstl).  Most  Dstl  PCS  study  programmes  support  UK  Ministry  of 
Defence  (MoD)  planning  processes  on  policy,  procurement  and  operations.  Conventional  combat  has  in  the 
past  been  the  core  study  area  for  Dstl  PCS.  To  support  this,  a  wide  range  of  OR  tools  and  techniques  have 
been  developed  to  support  Dstl  PCS’  study  programmes.  However,  since  the  end  of  the  Cold  War,  greater 
emphasis  has  been  placed  on  understanding  operations  that  fall  outside  of  conventional  combat.  In  recent 
years,  the  ever-increasing  commitment  of  the  UK’s  armed  forces  to  Peace  Support  Operations  (PSO)  has 
exposed  a  shortfall  in  high  level  modelling  tools  suitable  for  analysis  of  non- warfighting  military  tasks.  As  a 
consequence  of  this  shortfall  Dstl  PCS  is  in  the  process  of  restructuring  part  of  its  tool-set  to  meet  PSO  OR 
requirements.  DIAMOND  (Diplomatic  and  Military  Operations  in  a  Non- warfighting  Domain)  is  part  of  that 
programme. 

1.2  The  PSO  Modelling  Jigsaw 

Modelling  PSO  is  still  a  new  and  evolving  area  for  the  OR  community.  Rather  understandably  for  such  a 
young  discipline  there  are  many  pieces  to  the  ‘jigsaw’  but  not  yet  the  understanding  of  how  they  all  fit 
together  to  provide  the  complete  picture.  In  fact  it  could  be  argued  that  as  a  community  we  are  still  uncertain 
of  which  pieces  we  need  to  complete  the  jigsaw,  let  alone  how  they  fit  together.  Figure  1  represents  some 
aspects  of  this  jigsaw  and  some  of  the  pieces  we  have  access  to. 
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Figure  1:  The  PSO  Modelling  Jigsaw 

In  answering  any  OR  question  on  PSO  it  is  important  to  examine  the  tools  and  techniques  available  to  us  and 
decide  which  of  the  pieces  are  most  appropriate  to  answer  that  question.  Some  may  be  answered  from  a  single 
source  such  as  a  database  whereas  others  will  require  a  combination  of  tools  and  techniques.  Very  complex 
questions,  such  as  those  concerning  policy  and  force  structures,  require  a  wide  selection  of  tools  and  sources 
and  quickly  become  either  too  expensive  to  do  or  too  complex  to  examine  rapidly.  One  proven  way  to  offset 
these  disadvantages  is  to  deploy  simulation  models  that  focus  the  data,  techniques  and  understanding  from 
other  sources  and  provide  an  analytical  environment  in  which  to  study  complex  questions.  Figure  1  suggests 
that  there  is  currently  no  tool  available  which  fits  the  requirement  for  the  high  level  simulation  of  PSO. 
DIAMOND,  once  completed  and  validated,  will  fill  this  requirement  and  provide  a  simulation  model  suitable 
to  draw  on  the  surrounding  data,  tools  and  techniques  that  we  already  have  access  to. 

1.3  Requirement  for  DIAMOND 

DIAMOND  is  under  construction  to  address  Force  Development  issues  associated  with  peacekeeping,  peace 
enforcement  and  humanitarian  aid  operations.  Part  of  this  requirement  involves  providing  a  tool  to  assist  in 
answering  the  following  types  of  question: 

-  Which  force  elements  are  essential  to  maintain  the  military  mission? 

-  What  is  the  utilisation  of  each  force  element1  ? 

-  Are  force  elements  used  in  their  primary  role  or  do  they  substitute  for  high  demand  elements? 

-  Are  such  substitutions  efficient? 

-  How  robust  is  the  force  mix  option  in  adapting  to  changing  political  and  military  circumstances  in  theatre? 

-  What  is  the  ideal  force  mix  to  support  an  operation? 

-  What  is  the  ideal  force  structure  to  support  a  wide  variety  of  potentially  concurrent  operations? 

One  tool  to  answer  these  questions  is  a  simulation  model.  In  Figure  1,  High  Level  Simulation  (ergo 
DIAMOND)  is  shown  at  the  centre  of  the  puzzle.  This  is  not  to  suggest  that  DIAMOND  is  the  ‘final  piece’  in 
the  PSO  jigsaw  but  to  show  that  DIAMOND  links  into  all  the  pieces  that  surround  it.  For  high  level  force 
development  work  this  is  the  logical  arrangement  of  the  pieces  but  for  other  studies,  such  as  procurement  or 
balance  of  investment,  DIAMOND  may  sit  on  the  periphery  or  provide  no  significant  contribution  to  an  OR 
solution  at  all. 


1  Force  element  is  defined  as  a  company,  battery  or  individual  aircraft  or  ship. 
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It  is  also  important  to  state  that  the  current  design  for  DIAMOND  is  not  intended  to  provide  a  ‘single  model’ 
solution  for  analysing  policy  and  force  development  PSO  issues.  Although  many  aspects  of  the  other  tools 
and  techniques  can  be  incorporated  directly  into  DIAMOND  (e.g.  data  and  doctrine)  the  model  will  still 
require  indirect  support  from  other  areas.  For  example,  DIAMOND  may  rely  on  other  models  or  wargaming 
to  develop  an  initial  concept  of  operations  and  scope  the  political  constraints  for  any  given  scenario. 

For  any  study  there  will  inevitably  still  be  pieces  of  the  jigsaw  missing  but  as  our  understanding  of  PSO 
deepens  those  pieces  will  be  discovered  and  introduced  into  the  picture.  As  DIAMOND  is  an  evolutionary 
development,  the  model  will  be  continually  improved  to  take  into  account  our  increased  understanding  of  the 
domain  and  the  model  itself.  DIAMOND  has  already  highlighted  some  areas  where  we  have  either  very  little 
or  no  suitable  data  with  which  to  examine  particular  aspects  of  PSO  operations  (e.g.  refugee  movements)  and 
thus  its  development  can  be  used  to  focus  other  work  on  collecting  and  assimilating  information  for  study  use. 

1.4  Development  Programme 

The  DIAMOND  project  began  in  August  1998  with  a  series  of  workshops  to  scope  the  requirement  and  focus 
the  development  on  the  core  aspects  of  peacekeeping,  peace  enforcement  and  humanitarian  aid.  This  resulted 
in  the  production  of  an  outline  requirement  document  establishing  the  aims  and  boundaries  of  the  project. 
Following  this  a  detailed  requirement  was  written  later  that  year  as  the  foundation  for  all  future  work.  A 
further  eight  months  development  effort  followed  and  resulted  in  the  production  of  the  functional  specification 
which  outlined  how  the  requirements  would  be  implemented  to  produce  the  DIAMOND  model.  In  September 
1999  further  workshops  were  convened  to  complete  the  design  and  begin  the  process  of  coding  the  model. 

A  working  version  of  the  model  was  delivered  at  the  end  of  August  2000  with  the  model  to  be  validated, 
commissioned  and  in  use  during  2002.  As  the  project  is  an  evolutionary  development  it  likely  that  further 
design  and  coding  will  occur  after  this  date  to  build  on  lessons  learnt  and  to  incorporate  research  generated 
from  the  delivery  of  the  first  version  of  the  model. 

The  validation  exercise  has  examined  a  number  of  historical  operations.  These  operations  were  chosen  to 
meet  specific  aspects  of  the  validation  process  as  detailed  in  Figure  2.  The  intention  of  the  validation  exercise 
was  to  confirm  that  DIAMOND  could  be  used  to  generate  a  feasible  representation  of  the  historical 
operations,  it  was  not  intended  to  calibrate  the  model  to  them.  The  reason  for  this  is  that  the  historical  cases 
only  represent  one  possible  outcome  and  this  outcome  may  not  be  the  norm  for  operations  of  that  type.  The 
validation  has  concentrated  on  those  areas  of  the  model  for  which  we  have  supporting  data.  There  is  also  a 
parallel  stream  of  work  investigating  other  data  sources,  principally  in  those  areas  for  which  we  have  little  or 
no  prior  experience  of  modelling  (e.g.  the  humanitarian  aspects  such  as  food  and  water  requirements  and  the 
effect  of  diseases).  There  will,  of  course,  remain  some  data  items  that  we  cannot,  currently,  obtain  supporting 
evidence  for.  It  is  believed,  however,  that  the  existence  of  DIAMOND  will  provide  a  focus  (and  rationale)  for 
future  data  collection  efforts. 


Scenario 

Validation  Aspects 

Bosnia  IFOR,  1995 

Test  the  boundaries  of  the  model  in  terms  of  the  size  of  scenario  which  can 

(Peace  Keeping) 

feasibly  be  represented  and,  more  importantly,  analysed 

Mozambique,  2000 

Test  the  humanitarian  and  engineering  aspects 

(Humanitarian  Aid) 

Sierra  Leone,  2000 

Test  the  conflict  and  party  interaction  processes 

(Peace  Enforcement  / 

Evacuation) 

Figure  2:  Validation  scenarios 

The  model  was  developed  using  the  Rational  Rose  object-oriented  modelling  tool,  Visual  C++,  Windows 
NT4,  Microsoft  Foundation  Classes  and  DROMAS  version  2.63. 
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2  Technical  Specification 


2.1  Overview 

DIAMOND  is  a  fast  running,  high  level,  stochastic,  object-oriented  simulation  of  peacekeeping,  peace 
enforcement  and  humanitarian  aid  operations  (PSO).  The  major  aspects  of  the  technical  design  are 
summarised  below. 

A  simple  node  and  arc  network  provides  a  graphical  representation  of  the  region  and  environment  allowing 
the  model  to  represent  key  areas  of  interest,  areas  of  sea  or  lake  and  the  airspace  above.  Key  facilities,  such  as 
airports  and  civilian  shelter  can  be  represented. 

The  model  allows  for  the  representation  of  key  actors  and  contributors  to  PSO  by  use  of  Entities.  These 
represent  the  capabilities  and  behaviours  of  military  units,  civilians,  non-military  organisations  and  the  leaders 
or  commanders  for  each.  Entities  interact  with  each  other  and  the  environment  and  exchange  or  consume  key 
commodities  such  as  food,  fuel  and  ammunition. 

The  model  incorporates  a  mechanism  to  organise  entities  into  common  ‘parties’  that  represent  specific 
organisations  or  common  groups  within  a  scenario.  These  parties  have  an  appropriate  command  structure  and 
communications  network  to  facilitate  the  allocation  of  missions  and  flow  of  intelligence  throughout  the  party. 
Parties  have  relationships  with  one  another  which  define  their  interactions. 

The  model  includes  a  mechanism  to  represent  each  party's  concept  of  operations  by  nesting  objectives  in  a 
series  of  plans  and  for  those  objectives  to  consist  of  a  series  of  missions  that  entities  can  prosecute  during  a 
campaign.  Commanders  within  a  party  allocate  resources  to  achieve  their  objectives  in  line  with  the  sequence 
of  plans  and  the  simulation  completes  when  a  set  number  of  parties  achieve  their  end  state  conditions  or  when 
a  predetermined  period  of  time  has  elapsed. 

During  a  model  run  entities  gain  information  on  their  environment  and  other  entities  through  sensing, 
interactions  and  communication.  This  information  is  organised  into  a  local  picture  which  allows  those  entities 
to  make  informed  decisions  on  how  they  should  prosecute  their  missions  and  activities  delegated  to  them  by 
their  superior  commanders. 

Finally,  DIAMOND  includes  a  mechanism  (referred  to  as  negotiation)  to  obtain  access  to  an  area  denied  to 
one  party  by  another  and  to  allow  multi-party  co-operation  to  achieve  aims  and  objectives  without  having  to 
rely  entirely  on  their  own  resources. 

2.2  Environment  &  Facilities 

A  node  and  arc  network  provides  the  physical  environment  in  DIAMOND.  Nodes  represent  areas  of 
operational  interest,  population  centres  and  the  locations  of  key  infrastructure  and  terrain  features.  Arcs 
represent  the  routes  between  these  nodes.  An  example  Node  -  Arc  network  for  DIAMOND  is  shown  in 
Figure  3. 
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Figure  3:  Example  Node  -  Arc  network 


Nodes  can,  depending  upon  the  nature  of  the  scenario,  represent  whole  cities  such  as  London  or  individual 
districts  or  regions  within  a  city  such  as  Chelsea,  Lambeth,  Westminster  or  East  and  West  London.  They  can 
be  used  to  represent  individual  villages  but  it  is  proposed  that  a  more  appropriate  aggregation  level  would  be 
collections  of  villages.  Nodes  are  also  used  to  mark  areas  of  deep  water,  points  along  an  air  corridor,  strategic 
junctions  and  key  terrain  features. 

Arcs  represent  the  routes  between  the  nodes  and  each  one  has  several  channels  which  can  include  ground 
routes  (which  aggregates  the  road,  rail  and  cross  country  links),  air  corridors,  inland  waterways  (canal,  river, 
lake  crossing  aggregated),  littoral  waterways  and  deep  waterways.  The  anticipated  length  of  each  arc  is 
around  10  to  30km,  although  this  can  be  much  shorter  where  areas  of  interest  are  close  to  one  another  (e.g.  the 
districts  of  a  city). 

The  type  of  channel  (and  its  capacity)  determines  which  entities  can  move  down  that  arc.  For  example,  large 
ships  cannot  transit  an  arc  connecting  two  water  nodes  with  only  an  inland  waterway  channel  (e.g.  a  canal),  as 
they  are  prohibited  from  using  any  channel  that  is  not  a  deep-sea  waterway. 

When  defining  the  node/arc  network  (Net),  the  user  must  take  care  to  ensure  that  the  Net  is  established  with  a 
level  of  granularity  appropriate  to  the  entity  size,  i.e.  division-sized  entities  on  a  Net  where  individual  nodes 
represent  single  villages  and  settlements  would  be  inappropriate.  It  is  proposed  that  for  an  environment 
represented  as  cities,  towns  or  districts  with  arcs  between  10  to  30km  then  the  appropriate  entity  size  for 
military  units  is  battlegroup,  air  package2  and  individual  ship. 

Nodes  and  Arcs  both  have  a  terrain  type  (called  culture)  which  influences  a  variety  of  calculations  such  as  the 
effectiveness  of  sensors,  the  rate  of  attrition  between  two  units  engaged  in  combat  and  movement  rate.  These 
culture  types  are:  Urban,  Suburban,  Open  Flat,  Open  Rolling,  Open  Mountainous,  Scrub,  Lightly  wooded, 
Densely  wooded,  Mountainous  and  Open  Water. 

Weather  is  also  modelled  and  encapsulates  factors  with  local,  temporary  effect.  Weather  on  an  arc  defaults  to 
the  weather  of  the  nearest  node;  ergo  the  midpoint  of  arcs  is  where  weather  types  can  change  between 
different  areas  of  interest.  The  weather  condition  at  all  points  on  the  net  is  known  by  all  entities.  Advance 
forecasting  of  weather  is  not  modelled  in  the  first  release  of  DIAMOND  but  may  be  introduced  in  later 
developments.  Day  and  night  is  also  not  represented  but,  again,  may  be  introduced  in  subsequent 
developments. 

At  each  node  it  is  possible  for  the  user  to  define  facilities,  which  are  key  attributes  of  that  area  that  any  entity 
can  interact  with.  The  facilities  modelled  in  DIAMOND  are:  Shelter,  Hospitals,  Airports,  Seaports,  Targets. 
Each  facility  has  the  following  generic  attributes: 


2  Battlegroup:  approximately  3  to  4  companies,  Air  package:  approximately  1  to  4  aircraft. 
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Damage  points:  The  damage  points  for  a  facility  indicates  how  hard  it  is  to  eliminate.  Damage  points  are 
represented  by  two  fields:  the  maximum  damage  points  a  facility  can  sustain  before  it  is  eliminated  (or  at  least 
ceases  being  targetable  by  weapon  systems)  and  its  current  damage  points.  Note:  facilities  may  start  a 
scenario  already  part  damaged. 

Capacity  or  Output:  Most  facilities  produce  an  output  or  service  of  one  type  or  another.  For  example, 
shelter  has  the  capacity  to  house  people;  hospitals  have  the  capacity  to  treat  a  number  of  patients  per  day.  The 
capacity  or  output  is  different  for  each  facility  but  the  concept  of  capacity  is  generic  across  all  facilities.  The 
capacity  can  be  degraded  with  damage.  Therefore  there  are  2  fields:  maximum  capacity  and  current  capacity. 
Both  of  these  are  dynamically  calculated  at  the  start  and/or  throughout  a  run. 

Damage  point  to  Capacity  point  conversion  factors:  As  damage  points  inflicted  affect  the  capacity  of  a 
facility  the  relationship  between  damage  sustained  and  capacity  is  governed  by  the  Damage  point  to  Capacity 
point  conversion  factor. 

Self-Repair  capability  and  Self-Repair  Threshold:  Although  engineering  and  construction  entities  in  the 
simulation  perform  repairs,  all  facilities  are  likely  to  have  an  intrinsic  self-repair  capability  based  on  the 
manpower  and/or  specialist  equipment  at  the  site.  For  example,  civilians  can  repair  light  damage  to  their 
homes  by  boarding  up  windows,  replacing  missing  tiles  or  through  other  makeshift  repairs.  Plumbers, 
builders  and  other  specialists  within  the  community  could  repair  heavier  damage  and  would  not  necessarily  be 
represented  by  a  special  entity.  These  effects  are  represented  by  the  Self-Repair  capability,  which  is  the 
number  of  damage  points  that  facility  may  repair  itself  per  day.  Only  when  damage  is  very  heavy  and 
widespread  do  these  local  services  become  ineffective.  As  such,  the  self-repair  capability  of  any  facility  will 
be  limited  and  may  cease  to  operate  if  the  damage  is  heavy.  This  is  represented  by  the  Self-Repair  Threshold, 
which  is  the  number  of  damage  points  above  which  the  Self-Repair  capability  is  available. 

Residual  Capacity  and  Residual  Threshold:  Not  all  facilities  can  be  totally  destroyed  and  therefore  even 
when  fully  damaged  they  may  provide  a  residual  capacity.  For  example,  even  if  a  hospital  was  destroyed 
some  of  the  doctors  could  remain  in  the  area  and  operate  out  of  any  acceptable  premises.  Consequently,  a 
residual  capacity  is  another  general  attribute  of  facilities.  It  is  the  minimum  capability  a  facility  can  provide 
even  if  it  has  sustained  maximum  damage. 

2.3  Entities  &  Activities 

The  entities  in  the  model  can  be  considered  to  fall  broadly  into  the  four  categories  below: 

Intervention  Forces:  These  are  the  Peacekeeping  and  Peace  Enforcement  forces  with  entities  representing 
land,  air,  maritime  and  special  forces  units  operating  under  a  UN  or  other  international  mandate. 
Supplementary  police  forces  to  assist  a  failed  state  are  also  covered  under  this  category. 

Factions:  The  military  and  paramilitary  forces  of  belligerent  or  warring  factions  who  are  not  part  of  the 
peacekeeping  or  peace  enforcement  forces.  The  host  nation’s  forces  are  also  covered  under  the  heading  of 
factions.  The  entities  include  land,  air,  maritime  and  special  forces  units. 

Non-military  organisations  (NMOs):  NMOs  include  monitors  and  observers,  commercial  companies, 
governmental  and  international  humanitarian  agencies  and  non-governmental  organisations. 

Civilians:  Civilians,  including  neutral  civilians  and  those  associated  with  individual  factions,  internally 
displaced  persons,  refugees  and  evacuees. 

Each  of  these  categories  of  actor  can  be  represented  in  the  model  through  use  of  an  entity  template.  There  are 
5  types  of  template  available.  3  are  for  different  levels  of  commander,  1  for  civilians  and  the  other  is  a  generic 
template  used  to  describe  all  land,  sea,  air  and  NMO  entities.  In  summary  the  templates  are:  Joint  Theatre 
Commander,  Component  Commander,  Intermediate  Commander,  Civilian  Entity  and  Generic  Entity. 

Although  3  types  of  commander  are  specified  it  is  implicit  for  both  civilian  and  generic  entities  that  they  can 
command  themselves  if  they  have  no  direction  from  a  superior.  They  have  their  own  local  picture  and  are 
capable  of  making  decisions  for  their  own  survival  and  to  achieve  their  missions.  The  higher  level 
commanders  allow  for  additional  considerations,  such  as  deciding  which  stage  of  a  campaign  plan  should  be 
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followed,  allocating  resources  to  missions  and  directing  a  number  of  subordinate  entities  to  work  together  to 
achieve  a  common  goal. 

Each  template  allows  the  user  to  define  a  number  of  key  descriptors  for  that  actor  in  the  simulation:  movement 
rate,  size,  sensor  package,  combat  ability,  transport  capability,  civilian/military  identifier,  commodity 
consumption  rates,  communications  networks,  engineering  capability  and  the  missions  the  entity  is  eligible  to 
perform. 

The  proposed  aggregation  levels  for  land,  air  and  maritime  units  in  DIAMOND  are  battlegroup,  package  and 
single  ship  respectively.  Civilian  populations  can  vary  between  several  hundred  and  several  million  and 
NMOs  are  likely  to  be  small  units  of  variable  size  and  attributes. 

As  commanders  represent  headquarters,  local  government,  individuals  and  in  some  cases  the  intangible 
collective  actions  of  a  set  of  common  entities  (e.g.  refugees)  their  size  is  entirely  user  defined. 

To  allow  the  model  to  calculate  ‘entities  to  tasks’  all  entities,  regardless  of  their  size,  are  standardised  in  terms 
of  ‘components’.  For  military  land  units  a  component  represents  a  deployable  company  or  squadron  and  for 
maritime  and  air  forces  a  component  represents  a  single  ship,  boat  or  airframe.  This  choice  was  made  to  allow 
components  for  land  units  in  DIAMOND  to  map  directly  from  lower  level  combat  models  and  for  combat 
outcomes  from  those  models  to  populate  lookup  tables  in  DIAMOND. 

Although  no  detailed  work  has  been  done  on  what  is  an  appropriate  component  level  for  NMOs  it  is  proposed 
that  a  size  of  component  comparable  to  their  military  counterparts  be  used  in  the  first  instance.  Although  this 
will  mean  some  NMO  entities  will  represent  fractions  of  a  component  (e.g.  a  single  land  rover  and  two  aid 
workers  equals  about  0.02  of  a  component),  the  entities  to  task  rules  can  be  written  with  this  in  mind  and 
allow  DIAMOND  to  substitute  military  and  non-military  entities  between  tasks  (e.g.  bridge  repairs,  food 
distribution). 

2.4  Sensing  &  Communication 

In  DIAMOND,  sensing  &  communication  cover  the  processes  by  which  entities  directly  acquire  information 
about  other  entities,  events  and  the  environment.  Sensing  covers  3  processes:  direct  observation,  use  of  a 
sensor  such  as  radar  and  experience  of  events  such  as  interactions  with  other  entities  and  the  environment. 
The  representation  of  sensors  has  been  kept  as  simple  as  possible  for  the  first  release  of  DIAMOND.  Rather 
than  have  explicit  representation  of  known  sensors  such  as  radar,  optics  etc.  the  user  is  able  to  give  names  to 
generic  sensor  packages.  A  sensor  package  represents  the  collective  sensor  performance  of  that  entity.  For 
example,  a  British  battlegroup  can  have  numerous  visual,  IR  and  radar  sensors  plus  the  eyes  and  ears  of  over 
500  soldiers.  In  DIAMOND  this  can  be  represented  as  a  single  sensor  package.  A  unique  name  and  the 
component  types  it  is  capable  of  detecting  define  each  sensor  package. 

For  the  first  release  of  DIAMOND  ‘cookie  cutter’  templates  represent  the  range  of  sensors.  The  surrounding 
culture  type  of  any  target  entity,  the  size  of  that  entity  and  the  local  weather  conditions  modifies  these  ranges. 
Any  item  that  falls  within  this  adjusted  maximum  range  of  the  sensor  package  will  be  detected  and  all  entities 
that  fall  outside  will  evade  detection.  Different  ranges  within  the  cookie  cutter  determine  the  resolution  (i.e. 
the  detail)  that  the  sensor  information  can  provide  (Figure  4). 
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All  information  received  by  an  entity  (whether  that  be  through  sensing  or  communication)  is  assimilated  into 
its  local  picture.  The  representation  of  local  picture  (and  perceptions  based  upon  it)  is  an  important  aspect  of 
DIAMOND,  as  all  entities  decide  what  to  do  in  the  simulation  on  the  basis  of  the  information  available  to 
them.  If  this  information  is  incomplete  or  out  of  date  the  entity’s  actions  may  be  different,  compared  to  their 
actions  based  on  complete  and  current  information.  The  local  picture  in  DIAMOND  is  defined  as  the 
aggregation  of  all  information  made  available  to  that  entity  with  perfect  and  efficient  data  fusion.  Perception 
is  the  translation  from  what  that  perfect  picture  looks  like  into  what  the  entity  ‘believes’  it  knows.  For  the  first 
release  of  DIAMOND  local  picture  maps  1 : 1  onto  perception.  In  subsequent  developments  the  perception 
function  may  be  enhanced  to  allow  for  misinterpretation,  double  plotting  and  extrapolation  of  information  in 
the  local  picture. 

Each  piece  of  information  recorded  in  the  local  picture  consists  of  four  items.  They  are:  Unique  identifier, 
Resolution,  Credibility,  Timestamp. 

Unique  Identifier:  The  unique  identifier  records  the  individual  identity  of  every  object  in  the  simulation. 
This  information  is  required  by  the  model  to  ensure  the  same  object  is  not  plotted  twice  in  the  local  picture. 
As  the  local  picture  is  defined  as  the  most  efficient  fusion  of  data  the  model  will  always  plot  the  most  useful 
combination  of  information  relating  to  that  unique  object.  This  effect  is  not  true  for  the  perception  picture 
where  errors  may  occur  (i.e.  the  object  is  plotted  twice,  it  is  plotted  in  the  wrong  place,  it  is  mislabelled,  it  is 
mis-identified,  or  it  is  ignored).  However,  as  previously  stated,  perception  is  not  modelled  to  this  level  of 
detail  for  the  first  version  of  DIAMOND. 

Resolution:  The  resolution  class  determines  the  detail  of  the  information  available  about  that  entity.  There 
are  5  levels  of  resolution,  ranging  from  the  least  detailed,  detection,  through  to  the  most  detailed,  analysis.  In 
DIAMOND  as  soon  as  a  level  of  detail  is  acquired  about  another  object  it  is  time  stamped  against  the  unique 
ID  of  that  entity  and  the  specific  information  gathered  at  that  level  is  recorded  to  a  temporary  store.  That 
information  can  then  be  recalled  whenever  an  entity  consults  their  local  picture  about  that  specific  piece  of 
information. 

Credibility:  The  credibility  of  the  information  (which  is  dependant  upon  the  source  of  the  information, 
previous  credibility  assigned  to  that  information  and  the  entity  receiving  the  information)  is  also  recorded. 
There  are  5  levels  of  credibility  in  the  model,  ranging  from  certain  through  to  incredible.  Credibility 
influences  whether  entities  use  or  discard  that  information  when  they  make  decisions  based  upon  the 
information  in  their  local  picture.  In  the  first  version  of  DIAMOND  the  credibility  may  be  detached  from  the 
other  three  data  items  (resolution  class,  timestamp  and  unique  ID)  to  replace  a  lower  credibility  on  a  more 
accurate  or  up  to  date  version  of  the  same  object  (i.e.  better  resolution  or  timestamp). 

Timestamp:  It  is  important  to  timestamp  when  information  is  gathered  because  it  is  not  instantaneously 
transmitted  around  a  party’s  communications  network.  Hence  this  identifier  ensures  that  only  the  most  up-to- 
date  information  is  recorded  (not  necessarily  the  most  recently  received).  The  model  does  not  currently 
degrade  information  due  to  its  age  although  this  is  a  potential  future  enhancement. 

Communications  can  be  of  four  types: 

Regular:  Regular  (or  event  triggered)  communication  between  superiors  and  subordinates  within  a  single 
party’s  communication  network. 

Direct:  Communication  between  a  commander  and  a  subordinate  entity  from  a  different  party  who  has  been 
instructed  to  co-operate  by  its  superior  commander.  This  is  a  temporary  (dynamic)  link  that  will  end  when  the 
mission  they  are  co-operating  on  is  complete. 

Broadcast:  A  global  broadcast  that  reaches  all  entities  with  a  receive  capability  for  that  broadcast  type. 

Negotiation:  Negotiation  between  two  entities  from  different  parties  who  are  in  the  same  ‘peer  group’  (in  the 
current  implementation  of  DIAMOND  only  the  highest-level  commanders  can  negotiate).  Examples  include 
requests  for  escort,  requests  for  supplies  and  requests  for  access.  Negotiation  is  assumed  to  be  supported  by 
appropriate  communications  systems  (e.g.  radio  if  negotiating  at  distance,  interpreters  if  negotiating  face  to 
face). 
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For  communications  DIAMOND  represents  a  number  of  communications  networks.  Some  nets  (such  as 
military  networks)  are  party -based,  while  others  (such  as  commercial  news  stations)  are  ‘global’.  Messages 
communicated  include  orders,  status  reports,  requests  for  assistance,  intelligence,  local  picture  information 
and  media  broadcasts. 

An  entity  will  always  communicate  with  its  superiors  and  subordinates.  The  user  can  also  create  special  nets 
to  allow  communications  that  do  not  follow  the  command  structure.  For  example,  these  might  include  media, 
the  ‘rumour’  network  and  face-to-face  communication.  On  occasions  this  will  occur  dynamically  is  when  an 
entity  is  assigned  to  operate  for  a  commander  (possibly  in  another  party)  that  is  not  his  direct  superior.  Under 
these  circumstances  the  entity  will  report  directly  to  its  hierarchical  commander  and  to  the  commander  who 
has  Operational  Command  (OPCOM)  of  that  unit. 

Broadcasts  and  directed  messages  are  subject  to  delay  at  each  level  of  command.  Interoperability  problems 
within  a  multinational  force  can  be  represented  by  additional  delays  in  transferring  information  from  one  net 
to  another  when  an  entity  has  access  to  both.  In  DIAMOND  entities  from  different  parties  may  have  ‘receive’ 
only  links  with  other  parties  connected  to  the  communications  network  to  represent  the  sharing  of  intelligence. 


2.5  Missions  &  Decision  Making 

The  activities  of  entities  within  the  environment  are  governed  by  2  criteria.  Firstly,  the  missions  (i.e.  tasks) 
represented  in  the  model  that  entities  are  eligible  to  perform  and  secondly,  the  decision  making  processes  in 
each  party  that  determines  how  and  when  those  missions  should  be  prosecuted. 


There  are  12  missions  in  the  model.  They  are:  Transport,  Intelligence,  Move,  Engineering,  Defend,  Reserve, 
Evacuate,  Escort,  Presence,  Strike,  Secure  and  Deny  movement. 

The  majority  of  the  missions  cover  general  tasks  that  any  entity  in  the  simulation  could  undertake  (Transport, 
Intelligence,  Move,  Engineering,  Defend  and  Reserve).  The  other  missions  are  those  that  are  likely  to  be 
specific  to  either  the  peacekeeping  forces  (Evacuate,  Escort,  Presence  and  Strike)  or  to  the  belligerent  factions 
(Secure  and  Deny  movement).  This  is  not  to  prevent  the  missions  being  interchangeable  between  the  different 
parties  within  DIAMOND  but  to  indicate  that  the  design  has  focused  on  providing  specific  tasks  associated 
with  the  principal  actors  involved  in  PSO.  Each  of  the  missions  is  interpreted  by  the  entities  that  perform 
them  as  a  series  of  activities.  For  example,  the  transport  mission  consists  of  the  sequence:  Plan,  move, 
commodity  exchange  (i.e.  load),  move,  commodity  exchange  (i.e.  unload),  reserve  (i.e.  become  available  for  a 
new  task)  and  communicate  (i.e.  report  to  superior  commander  that  the  entity  is  now  available  for  new 
missions). 

The  missions  themselves  are  organised  into  concurrent  and  sequential  packages,  referred  to  as  plans.  For 
example,  a  plan  may  include  a  mission  to  secure  an  area  after  which  several  transport  and  presence  missions 
may  occur  concurrently.  The  entities  undertaking  the  missions  within  the  plan  report  at  regular  intervals 
whether  they  are  succeeding  or  failing  and  their  superiors  may  allocate  additional  resources  (if  they  have 
them)  to  move  failing  missions  back  towards  success.  The  relationship  between  plans,  missions  and  activities 
is  shown  below  in  Figure  5. 


•A  sequence  of  plans  which  describes  each  party’s  options  during 
an  operation. 

•A  group  of  missions  linked  by  logical  initiation  conditions. 

•A  set  sequence  of  activities. 

•The  smallest  divisible  action  any  entity  can  perform. 


Figure  5:  Relationship  between  plans,  objectives,  missions  and  activities 
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Monitoring  the  overall  progress  of  the  plan  is  the  Joint  Theatre  Commander  (JTC)  or  his  NMO  equivalent. 
The  JTC’s  perceptions  include  a  function  called  the  Campaign  State  Vector  (CSV)  and  it  is  the  CSV  that 
indicates  to  the  JTC  whether  the  plan  is  succeeding  or  failing.  Each  plan  has  an  associated  set  of  initiation 
conditions  and  end  conditions,  which  may  be  time  dependent  and/or  success  dependent.  If  a  plan  is  failing 
(or  has  completed)  the  JTC  will  decide  which  is  the  next  most  appropriate  plan  to  follow.  This  sequence  of 
plans  forms  the  party’s  Concept  of  Operations  (Figure  6). 
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Figure  6:  Example  of  a  party ’s  Concept  of  Operations 

The  3  types  of  commander  in  DIAMOND  make  decisions  associated  with  the  progress  of  plans  or  missions. 
The  levels  of  commander  are  the  Joint  Theatre  Commander  (JTC),  the  Component  Commanders  (CC)  and  the 
Intermediate  Commanders  (IC).  There  is  technically  a  fourth  level  of  commander,  the  entities  themselves 
(military  units,  NMO’s  and  civilians).  This  is  shown  diagrammatically  in  Figure  7. 


Figure  7:  Command  and  control  hierarchy 

The  JTC  controls  the  progress  of  the  campaign  by  deciding  which  plan  to  follow  at  any  time.  Beneath  the 
JTC  sit  the  component  commanders.  The  component  commanders  represent  land,  sea  and  air  forces  or  could 
represent  national  contingents  within  a  coalition.  They  ‘size’  each  of  the  missions  within  a  plan  and  delegate 
operational  command  to  an  appropriate  intermediate  commander  in  the  party’s  hierarchy.  For  example,  if  the 
mission  were  suitable  for  a  division  then  the  responsibility  for  conducting  the  mission  would  be  applied  at  the 
divisional  level. 

It  is  the  intermediate  commanders  that  represent  this  command  chain  with  multiple  levels  representing  (for 
example)  battalion  commanders  up  to  corps  commanders.  They  act  upon  the  reports  of  their  subordinates  and 
manage  their  assigned  mission  as  best  they  can.  Should  additional  resources  be  required  beyond  what  the  IC 
can  provide  then  they  need  to  be  requested  from  a  superior. 
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Below  the  intermediate  commanders  are  the  entities  themselves.  Their  command  attributes  are  limited  to 
prosecuting  the  activities  that  make  up  a  mission  and  taking  local  decisions  to  enhance  their  survival  or 
chances  of  success. 

It  is  the  combination  of  all  these  processes  that  allows  the  simulation  to  run  without  user  assistance  once  a 
scenario  has  been  scoped  and  developed.  It  is  the  development  and  testing  of  plans  and  mission  sequences 
that  requires  the  greatest  input  from  the  user.  The  majority  of  the  processes  related  to  sizing  of  missions  and 
managing  resources  will  be  based  on  doctrine  or  operational  experience. 

2.5  Relationships 

In  existing  combat  models  it  has  been  traditional  to  represent  only  2  sides  of  any  conflict.  This  is  a  suitable 
assumption  for  most  conventional  battles  as,  regardless  of  the  number  of  participants,  they  tend  to  fall  into  the 
categories  of  friend  or  foe.  In  non-warfighting  operations  this  assumption  is  not  valid,  as  there  are  often  a 
large  number  of  participants,  none  of  which  can  be  classified  purely  as  hostile  to  each  other.  For  example,  in 
Bosnia  there  were  3  main  armed  factions,  their  respective  civilian  populations  and  the  peacekeeping  forces.  In 
Somalia  there  were  upwards  of  24  warlords  vying  for  control,  the  embattled  civilians,  the  multinational 
peacekeeping  forces  and  United  Nations  personnel,  all  of  which  were  of  strategic  importance  to  the  operation 
at  one  time  or  another.  Very  quickly  it  becomes  obvious  that  any  successful  attempt  to  model  non-warfighting 
operations  requires  a  multi-sided  approach.  It  was  decided  that  each  side  in  the  simulation  would  be  identified 
as  a  separate  party  and  that  the  relationships  between  those  parties  would  be  used  to  describe  their  affiliations, 
rather  than  aggregating  like-minded  parties  into  distinct  sides. 

In  accepting  that  a  multi-sided  model  is  required  it  is  necessary  to  identify  the  relationships  that  will  be 
required  to  describe  the  affiliations  of  each  party.  Again,  in  traditional  combat  modelling  only  one  type  of 
relationship  is  modelled,  that  of  hostility  between  parties.  In  non-warfighting  models  a  greater  range  of 
relationships  is  required.  Research  at  Dstl  has  determined  the  minimum  number  of  relationships  required  to 
represent  basic  inter-party  behaviour  is  5:  Hostile,  Uncooperative,  Neutral,  Sympathetic  (co-operative)  and 
Friendly. 

Every  entity  within  a  party  must  share  that  party’s  relationships.  For  example,  if  a  party  of  peacekeepers  were 
neutral  to  the  party  of  belligerents  then  every  entity  and  commander  within  the  peacekeeping  party  must  share 
that  view  and  see  themselves  as  neutral  also. 

It  was  further  recognised  that  a  relationship  between  two  parties  does  not  have  to  be  symmetric.  For  example, 
an  NMO  (Non-Military  Organisation)  may  consider  its  relationship  with  a  belligerent  faction  as  neutral 
whereas  that  faction  may  adopt  an  uncooperative  or  even  hostile  stance  in  return.  In  the  first  release  of 
DIAMOND,  for  simplicity,  a  party  will  always  know  the  stance  of  other  parties  towards  them,  even  if  it  is  an 
asymmetric  relationship.  This  leads  to  the  possible  relationship  pairings  depicted  in  Figure  8.  Those  marked 
with  an  asterisk  are  probably  unstable  relationships  and  would  decay  quickly  to  another  relationship  on  the  list 
once  interactions  begin  between  the  two  parties.  However,  this  dynamic  change  in  relationships  is  not 
represented  in  the  current  implementation. 
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Figure  8:  The  15  possible  relationship  pairings 


2.6  Negotiation 

There  are,  in  PSO,  many  types  of  negotiation  that  occur  through  the  life  of  any  operation.  Mediation  to 
resolve  local  disputes,  negotiation  to  obtain  a  cease-fire  and  negotiation  to  obtain  access  are  just  a  few.  The 
types  of  negotiation  the  model  is  able  to  handle  are: 
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-  Negotiation  for  access 

-  Negotiation  for  support 

-  Requests  for  humanitarian  assistance 

-  Requests  for  escort 

-  Requests  for  supplies  (including  demands  and  theft) 

Each  type  of  negotiation  plays  an  important  role  in  restoring  normality  or  ensuring  that  potentially  escalatory 
situations  are  resolved  with  the  minimum  amount  of  force  by  either  side.  As  such  aspects  are  an  important 
part  of  PSO  it  is  important  that  DIAMOND  represents  some  elements  of  these  interactions  and  their  outcomes. 

However,  from  the  analytical  community  there  has  been  very  little  related  work  on  representing  negotiation  in 
a  manner  that  is  suitable  for  fast  running  simulation  models.  Consequently,  DIAMOND  has  taken  a  two-path 
approach  to  representing  some  of  the  aspects  of  negotiation.  The  first  path  is  the  use  of  historical  analysis  and 
the  second  is  to  provide  a  mechanism  that  will  allow  the  user  to  enter  into  the  model  the  insights  from 
Political-Military  (Pol-Mil)  gaming  so  that  they  can  be  interpreted  dynamically  by  the  model. 

These  approaches  will  allow  DIAMOND  to  become  the  first  stage  in  an  evolutionary  process  for  modelling 
cross  party  negotiation  in  PSO.  Should  either  or  both  techniques  prove  successful  then  further  development 
will  follow. 

Due  to  the  time  and  expense  incurred  in  conducting  historical  analysis  only  negotiation  for  access  is 
represented  with  this  approach.  Roadblocks  and  other  routeblocks  are  a  major  hindrance  to  peacekeeping 
operations,  preventing  or  delaying  free  movement  of  peacekeepers,  aid  agencies  and  civilian  traffic  alike. 
They  occur  for  a  variety  of  needs,  some  through  a  genuine  military  reason  to  secure  an  area,  some  as  a 
revenue  source  (tax  and  theft)  and  some  simply  because  the  protagonists  are  bored  and  see  it  as  a  means  to 
exert  their  authority  and  pass  time  (Goodwin,  1999). 

It  is  intended  to  conduct  historical  analysis  on  negotiation  for  access  to  identify  the  principal  factors  that  affect 
the  outcome.  It  is  believed  that  current  relationship,  force  ratio,  rules  of  engagement  and  a  unit’s  current 
mission  are  some  of  those  factors.  The  input  data  to  DIAMOND  will  be  configured  to  match  the  important 
factors  and  referenced  against  a  historical  model  derived  from  historical  analysis.  The  output  from  this  will  be 
the  time  taken  for  a  unit  to  negotiate  and  the  probability  of  it  successfully  obtaining  access. 

There  are  some  limitations  in  adopting  this  approach.  The  historical  analysis  conducted  may  be  very  region  or 
context  specific  and  may  not  allow  for  a  fully  generic  approach.  However,  by  ensuring  that  the  historical 
analysis  conducted  focuses  on  areas  or  situations  representative  of  the  likely  PSO  contingencies  there  will  be 
value  in  the  data  obtained  for  study  use  if  not  directly  for  DIAMOND  itself. 

The  other  types  of  negotiation  that  can  be  represented  in  the  model  will  rely  upon  Pol-Mil  gaming  or  expert 
judgement  to  define  the  conditions  on  which  such  a  negotiation  may  produce  a  result.  In  these  cases  the  time 
taken  to  conclude  any  negotiations  will  be  represented  and  the  model  will  represent  the  effect  of  a  successful 
negotiation.  Negotiation  is  confined  to  the  missions  represented  within  the  model.  For  example,  a  party  could 
request  a  transport  mission  or  intelligence  from  another  party  but  it  could  not  negotiate  a  local  cease  fire  in 
this  version  of  DIAMOND  (as  there  is  no  specific  mission  associated  with  cease-fires). 

These  other  types  of  negotiation  can  be  generically  referred  to  as  ‘negotiation  for  co-operation’,  although  that 
co-operation  may  in  itself  be  as  a  result  of  a  threat  or  other  aggressive  activity.  The  user  defines  whether  co¬ 
operation  on  any  mission  could  occur  with  another  party  for  each  possible  relationship  pairing  and  should  co¬ 
operation  be  possible  the  analyst  defines  which  missions  they  would  co-operate  on. 

2.7  Combat 

Combat  is  not  intended  to  form  a  major  part  of  any  DIAMOND  scenario.  However  as  one  of  the  main  tasks 
of  military  forces  in  PSO  in  the  provision  of  a  secure  environment  there  is  always  the  potential  for  conflict. 
The  representation  of  combat  within  the  current  implementation  is  mainly  limited  to  its  impact  on  ground 
forces,  there  is  no  representation  of  air-to-air  or  maritime  engagements.  This  is  not  deemed  to  be  a  major 
limitation  as  the  key  focus  of  the  majority  of  the  scenarios  that  could  be  modelled  in  DIAMOND  will  be  the 
land  forces. 
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The  basic  combat  process  is  similar  to  CLARION,  the  high-level  land  combat  simulation  used  within  Dstl 
PCS.  Unit  strengths  are  measured  using  a  static  scoring  method,  BAMS  (Balanced  Analysis  &  Modelling 
System)  and  effectiveness  data  is  based  on  the  results  of  more  detailed  (lower-level)  models.  Combat  is 
initiated  when  all  of  the  following  conditions  are  met: 

-  opposing  units  are  either  situated  within  the  same  node  or  within  a  user-defined  distance  along  arcs 

-  at  least  one  of  these  units  is  aware  of  the  other  (i.e.  it  is  in  its  local  picture) 

-  the  force  ratio  is  above  the  withdraw  level  of  all  units 

-  Rules  of  Engagement  (ROE),  and  by  implication  the  relationship  between  the  opposing  units,  permit  the 
engagement 

After  initiation  combat  continues  until  all  the  units  on  one  side  are  defeated.  If  additional  units  join  the 
combat  then  the  situation  is  reassessed  according  to  the  same  initiation  criteria. 

This  basic  combat  process  has  been  enhanced  for  DIAMOND  to  take  account  of  the  multi-sided  nature  of  the 
model.  This  is  achieved  through  the  use  of  ROE.  These  also  allow  the  representation  of  the  deterrence  or 
conflict  prevention  function  of  peacekeeping  forces.  ROE  can  be  individually  defined  for  every  mission  but 
the  standard  approach  is  to  use  a  number  of  templates,  each  tailored  toward  specific  mission  types.  These 
ROE  are  only  known  by  the  owning  party  -  it  does  not  know  the  ROE  of  other  parties. 

The  ROE  are  defined  by  the  relationship  to  other  party  and  determine: 

-  can  the  unit  open  fire  first  or  in  response  only 

-  who  or  what  can  be  targeted  e.g.  civilian  or  military  targets 

-  can  the  unit  respond  on  behalf  of  a  third  party  or  facilities 

-  quantity  of  fire 


The  careful  use  of  these  ROE  can  allow  the  representation  of  situations  unique  to  PSO: 

the  interposition  of  a  peacekeeping  force  between  warring  factions  to  stop  conflict 
the  deterrence  effect  of  peacekeeping  forces  preventing  conflict 
the  provision  of  security  to  the  civilian  population 


II 


Figure  9:  Example  of  combat  and  the  impact  of  ROE 

Figure  9  shows  an  example  of  how  combat  works  within  DIAMOND.  The  Red  armoured  units  (")  advance 
into  the  node  attacking  the  civilians  and  industrial  facilities  (which  would  be  represented  as  ‘target’  facilities 
in  DIAMOND)  that  are  there.  They  do  not  attack  the  medical  facilities  as  their  ROE  do  not  permit  them  to  do 
this.  The  relationship  between  the  Red  and  Blue  forces  (the  infantry  units,  !,  based  at  the  node)  is  such  that 
normally  they  would  not  engage  each  other.  However,  the  ROE  for  the  Blue  forces  allow  them  to  go  the 
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defence  of  the  civilian  population  and  hence  start  to  attack  the  Red  forces.  As  a  result  of  this,  the  Red  forces 
switch  their  attention  to  the  Blue  forces  as  they  present  the  biggest  threat.  The  combat  will  end  when  either  of 
the  forces  withdraws.  If  it  is  the  Blue  force  that  withdraws  then  Red  will  switch  back  to  attacking  the  civilians 
and  industry. 

The  previous  example  could  be  modified  such  that  the  Red  forces  only  attacked  the  industrial  facilities.  In 
this  case,  the  ROE  for  Blue  would  not  allow  them  to  engage  Red  as  the  Red  forces  were  not  attacking 
civilians. 

The  example  could  also  be  modified  to  demonstrate  the  deterrence  effect  of  a  peacekeeping  force.  In  this  case 
the  ROE  for  the  Red  forces  could  be  set  up  to  assume  that  Blue  will  attack  Red,  irrespective  of  Red’s  other 
actions.  Conversely,  as  Blue  is  a  peacekeeping  force,  its  ROE  are  set  up  to  only  act  in  self-defence  or  on 
behalf  of  the  civilian  population.  Hence  the  Red  assumption  is  incorrect  but  it  is  unaware  of  this.  In  this  case, 
if  the  combat  power  of  the  Blue  forces  is  sufficient  then  no  combat  will  occur  at  all.  If  the  combat  power  of 
Blue  is  insufficient  then  combat  will  occur  as  Blue  would  then  be  in  a  position  of  having  to  defend  itself. 

3  Conclusions 

In  summary,  DIAMOND  has  been  designed  specifically  to  tackle  OR  questions  relating  to  high-level  defence 
policy  and  force  development  issues.  Once  developed,  validated  and  populated  DIAMOND  will  allow  the  OR 
community  to  examine  these  areas  economically  and  quickly  and  act  as  a  focus  for  the  application  of  other 
tools,  techniques  and  data  collection.  Where  possible  the  design  has  been  kept  firmly  rooted  in  accepted  and 
validated  modelling  techniques  and  driven  by  known  data  sources.  However,  to  obtain  as  full  a  coverage  of 
the  PSO  domain  as  possible  it  has  been  necessary  to  develop  new  techniques  and  mechanisms  and  cite  the 
requirement  for  new  classes  of  data  or  algorithms  to  be  developed.  As  our  understanding  of  the  PSO  domain 
evolves  so  too  will  DIAMOND  to  take  advantage  of  any  new  work  and  insights. 
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Background 


Terminology 


•  Non-warfighting  operations 

•  Operations  Other  Than  War 

•  Other  Operations 

•  Peace  Support  Operations  (PSO) 

•  Crisis  Response  Operations 

•  Diplomatic  &  Military  Operations 

•  Small  Scale  Contingencies 

•  Security  And  Stability  Operations 


Requirement  for  analysis  of  PSO 

Increasing  commitment  of  forces  to  PSOs 

_ I _ 

Dstl  is  required  to  support  executive  decision 
makers  in  UK  MoD  with  operational  research 

_ I _ 

Dstl’s  existing  toolset  is  focussed  towards 
_ warfighting  operations _ 

_ I _ 

Dstl  is  restructuring  part  of  its  toolset  to  meet 
PSO  operational  research  needs 
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High  Level  Simulation  -  Requirement 


•  Address  issues  associated  with  PSO  at  the  theatre/campaign 
level 

•  Assess  robustness  of  force  structure  against  a  variety  of 
political/military  environments  encountered  in  PSO 

-  Assess  effectiveness  of  force  mix 

-  Assess  impact  of  varying  scales  of  effort 

-  Assess  utilisation  of  force  elements 

•  Complement  the  CLARION  and  COMAND 

•  Potential  feed  into  SABRINA 


Development  Programme 


1998  1999  2000  2001  2002 

_ Q1  Q2  Q3  Q4  Q1  Q2  Q3  Q4  Q1  Q2  Q3  Q4  Q1  Q2  Q3  Q4  Q1  Q2  Q3  Q4 

Model  scoping 

Detailed  requirements  definition 

Initial  model  specification 

Initial  model  design 

Model  coding 

Validation 

Model  in  service 


•  Initial  use  of  model  in  studies  -  Q2  2002 

•  Initial  use  will  help  to  define  future  development  needs 
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Part  2: 

Technical  overview 


Overview 


•  DIAMOND  is  to  be  a  fast  running, 
stochastic  model 

•  Represents 

-  Theatre  of  Operations 

-  C2  driven 

-  Belligerent  factions 

-  Peacekeeping  forces 


•  New  Aspects 

True  multisided  modelling 

-  Civilians 

Non-military  organisations 

Negotiation  between  parties 
(access  &  support) 

-  Rules  of  Engagement 
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Environment  &  Facilities 


•  Node  and  arc  representation  of 
theatre  of  operation 


•  Aggregation  level  (environment) 

Nodes:  Typically  major  population 
centres 

-  Arcs:  Typically  10  -  30km  in  length 
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Environment  &  Facilities  (2) 


Villages  2( 


Nodes 


Culture 

Area 

Fixed  transit  time 
Control  marker 
Background  law  and  order 
Facilities  &  commodity  generation 


Village  1 


Valley  pass 


High  ground 
overlooking  city 


/Node/arc  interface  facilities 

-  Bridges/Tunnels 
-  Route  Delay 

Facilities  -  (mines/checkpoint) 

-  Shelter  -  (weather,  route  damage) 

-  Water  resources  (on/off) 

-  Food  production 
-  Hospitals  (treatments  per  day) 

-  Seaport 
-  Airport 

-  ‘Target’  facilities 


Arcs 


Culture 

Channels  (e.g.  ground) 
Length  modifier 
Speed  modifier 
Capacity 
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Entities 


•  Entities  (Templates) 

Commander  (3  types) 
Generic  (military/NMO  etc.) 
Civilian  (refugees  etc.) 

•  Aggregation  level  (military) 

-  platoon  to  battalion 
Packages  of  1  to  4  aircraft 

-  Single  ship 

•  Aggregation  level  (other) 

-  NMO  always  variable 
Civilian  (100’s  to  millions) 
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Entity  Activities 


•  The  Activities  are: 

-  Plan 

Communicate/Negotiate 

-  Sense 

-  Move 

-  Damage/Repair 

-  Block  Route 

-  Wait  (Reserve) 

-  Combat 

-  Presence 
Consume  commodities 
Commodity  exchange 


23  September  2005 
©  Dstl  2001 


Environment 


Commodities 


Entities  consist  of 

-  An  appropriate  decision  making  profile 

-  Sensor  size  (undetectable  to  large) 

-  Civilian/military  identifier  (for  ROE) 

-  Logistic  capability 

-  Engineering  capability 

-  Sensor  capability 

-  Strike  capability 


Sensing  &  Communication 


•  Entities  gain  information  from 

-  Communication 

-  Sensors 

-  Interactions 

•  All  information  consists  of 


Resolution 


-  Credibility 

-  Timestamp 

•  All  information  organised  into  Local 
Pictures 


Local  Picture 

-  Covers  area  of  interest 

-  Entities  (last  known  information) 

-  Environment  (ground  truth) 

-  Maps  1:1  onto  perception 
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Sensing  &  Communication  (2) 


•  Information  Resolution 

-  Detection 

Status  Recognition 

-  Entity  Recognition 

-  Identification 

-  Analysis 


•  Information  Credibility 

-  Incredible 

-  Uncertain 

-  Possible 

-  Probable 

-  Certain 
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Missions  &  Decision  Making 


•  All  parties  begin  with  a  series  of  nested 
PLANS 

-  Plans  are  controlled  by  the  perception 
of  joint  theatre  commander 

•  Plans  consist  of  sequences  of 
OBJECTIVES  which  are  based  on  a 
series  of  MISSIONS  and  mission  areas 

•  There  are  12  mission  templates 

•  A  mission  is  a  set  sequence  of 
ACTIVITIES  e.g.  Transport 

Plan,  Move,  Commodity  Exchange, 
Move,  Reserve,  Communicate 
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Missions  &  Decision  Making  (2) 


•  General  missions 

-  Transport 

-  Evacuate 

-  Intelligence 

-  Move 

-  Engineering 

-  Reserve 


•  Peacekeeper  /  Belligerent  missions 

-  Escort 

-  Presence 

-  Defend 

-  Deny  movement 

-  Secure 

-  Strike 
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Commanders  and  C2 


•  High  Level  Commander 

-  Campaign  progress 

•  ‘Component  Commander’  (CC) 

-  Allocation  of  missions  and 
resources 

•  Intermediate  Commander  (1C) 

Operational  Command  of  individual 
missions 

•  Entities 

-  Prosecution  of  missions 
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Relationships  &  Negotiation  (1) 


•  Concept  of  relationships  essential  for  multisided  modelling 

•  5  basic  relationships 

-  Friendly 

-  Co-operative 

-  Neutral 

-  Uncooperative 

-  Hostile 

•  Allows  co-operative  (and  uncooperative)  behaviour,  not  just 
conflict  and  indifference 


Relationships  &  Negotiation  (2) 


•  Two  Negotiation  types 
Negotiation  for  access 
-  Negotiation  for  support 


High 

Comrr 

Level 

lander 

4 

Commander 

Commander 

Commander 

Commander  Entity 


Entity  Entity 


Entity  Entity 
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Relationships  &  Negotiation  (3) 


Negotiation  for  Support 

•  Support  limited  to  the  12  missions 
types 

•  Access  to  resources 
(Food/Fuel/Ammo) 

•  Yes/No  result  depends  on 
Relationship 

•  Cross  party  comms  delays 


•  (Requires  expert  judgement  to 
scope  support  matrix) 


Transport 


Combat  (1) 


•  Impact  limited  mainly  to  ground  forces 

-  Currently  no  air-to-air  or  ship-to-ship  engagements 

•  Effectiveness  based  upon  lower  level  modelling 

-  e.g.  SIMBAT,  air-to-ground  and  artillery  studies 

•  Combat  associated  missions 

-  Secure,  Defend,  Strike 

-  Deny  movement,  Escort 


Rules  of  Engagement 


•  Specific  Rules  of  Engagement  template  for  each  mission 

-  User  defined 

•  Impact  of  ROE  defined  by 

-  Relationship  to  other  party 

-  Open  fire  first?  Or  response  only 

-  Who  or  What  can  be  targeted  e.g.  civilian  or  military  targets 

-  Response  on  behalf  of  third  party  or  facilities 

-  Quantity  of  fire 


Combat  (2) 


•  Unit  strengths  in  Balanced  Analysis  &  Modelling  System  (BAMS) 

•  Combat  between  entities  depends  on  these  key  factors: 

-  Combat  initiation 

•  Entity  sensors 

•  Rules  of  Engagement 

•  Withdraw  or  stand  force  ratio 

-  During  combat 

•  Unit  effectiveness  versus  target  type 

•  Defeat  level  percentage 

•  Minimum  legitimate  target  strength 


Example  of  ROE  behaviour 


Blue  will  engage  Red  because  his 
ROE  allow  him  to  go  to  the  defence 
of  civilian  entities 


Red  armoured  units  entering  node 
engage  civilians  and  industrial 
facilities 

Red  cannot  engage  hospital  due 
their  ROE  constraints 


to 
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Part  3: 

Current  &  Future  Work 


Current  Work 


•  ‘Validation’ 

-  Bosnia  IFOR  (Dec  1995  -  Nov  1996,  Historical  operation) 

-  Sierra  Leone  (May  -  June  2000,  Historical  operation) 

-  Mozambique  (Feb  -  Mar  2000,  Historical  operation) 

•  Data  Paper 

•  Development 

-  Resolve  items  arising  from  the  validation 

No  addition  of  new  functionality  until  completion  of  validation  phase 


International  Collaboration 


•  Specification 

-  David  Davis,  Col  Jim  Narel:  George  Mason  University 

•  Briefing  /  Evaluation 

-  ANN  WG:  NO  -  FFI,  NL  -  TNO-FEL 

-  TRAC  Leavenworth  (USA):  Kent  Pickett  (AWARS) 

-  DMSO(USA) 

-  CAA  (USA) 

-  DSTO  (Australia) 

-  Symposia,  Conferences:  NATO  SAS  Panels,  Cornwallis,  ISMOR 


Way  Forward 


•  Study  use 

•  Expectation  management 

•  Continuing  development,  including  within  international 
community 
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Summary 


•  DIAMOND  is  a  purpose  built  simulation  of  PSO  that  addresses 

-  Dynamic  and  auditable  assessment  of  PSOs  for  UK  and  coalition  forces 

-  Multisided  scenarios  with  co-operative  and  uncooperative  activities 
performed  by  a  range  of  actors  from  civilians  through  to  military  forces 

•  Data  collection 

-  DIAMOND  is  already  providing  a  framework  for  structuring  data  collection 
and  processing 

•  Evolutionary  approach 

-  DIAMOND  will  evolve  as  our  understanding  of  PSO  improves 


Questions? 


